Method and system for signaling communication configuration for iot devices using manufacturer usage description files

ABSTRACT

A method at a network element for configuration for Internet of Things (IoT) devices using manufacturer usage description (MUD) files, the method including receiving at least one MUD Uniform Resource Locator (URL) from an IoT Device; sending, from the network element to at least one MUD Server based on the MUD URL, a Uniform Resource Indicator; responsive to the sending, receiving a plurality of MUD files from the MUD server; creating a plurality of policies from the plurality of MUD files, the plurality of policies corresponding to a normal mode of operation and a secondary mode of operation; and forwarding the plurality of policies to a gateway from the network element.

FIELD OF THE DISCLOSURE

The present disclosure relates emergency service response, and inparticular relates to the provision of supplementary data to emergencyservice providers.

BACKGROUND

Some Internet of Things (IoT) devices provide information that must bemade continuously available to emergency services. Examples of suchdevices include smoke or fire alarms that may provide informationimmediately to the fire services or a burglar alarm or intrusiondetection system that may provide information immediately to a policeforce, among others. Such devices are termed herein as “Class 1”devices.

However, other types of IoT devices are not used for the purposes ofindicating the onset of a safety or security event, but may provideuseful functionality in the handling of an emergency event. Examples mayinclude, among others, light bulbs that can tell firefighters whetherthe building is illuminated or thermometers which may be able to tellthe fire services about the way a fire is spreading. Other cases includeactuators that may control doors that are used for safety (fire doors)or for security, which only allow authorized people to enter or exit.Such IoT devices are termed herein as “Class 2” IoT devices.

Class 2 IoT devices are typically connected to communication networksand cloud-based applications, but typically do not include afunctionality that is made available to emergency services.

BRIEF DESCRIPTION OF THE DRAWINGS

The present disclosure will be better understood with reference to thedrawings, in which:

FIG. 1 is a block diagram showing an example Internet of Thingscommunication architecture;

FIG. 2 is a block diagram showing an example Manufacturer UsageDescription (MUD) architecture;

FIG. 3 is a dataflow diagram showing MUD Policy retrieval;

FIG. 4 is a dataflow diagram showing instantiation of a MUD system;

FIG. 5 is a dataflow diagram showing an example Bootstrapping Remote KeyInfrastructure (BRSKI) message flow;

FIG. 6 is a block diagram showing an example of utilizing MUD and BRSKIsequentially;

FIG. 7 is a block diagram showing an example of utilizing MUD and BRSKIsimultaneously;

FIG. 8 is a dataflow diagram showing the configuration and operation ofan IoT device in both a normal and an emergency mode of operation;

FIG. 9 is a dataflow diagram showing the sending of separate MUD URLsand the receiving of two policies at a router or gateway;

FIG. 10 is a dataflow diagram showing the sending of a single MUD URLand the receiving of two policies at a router or gateway;

FIG. 11 is a dataflow diagram showing the transition from a normal modeof operation to an emergency mode of operation based on a decision at anIoT application server;

FIG. 12 is a dataflow diagram showing the transition from a normal modeof operation to an emergency mode of operation based on a decision at aswitch;

FIG. 13 is a dataflow diagram in which a MUD manager retrieves theemergency contact information and adds such information at the localdomain side;

FIG. 14 is a dataflow diagram in which an Original EquipmentManufacturer server retrieves and adds the emergency contact informationin a system including both BRSKI and MUD;

FIG. 15 is a dataflow diagram in which an Original EquipmentManufacturer server retrieves and adds the emergency contact informationin a system including only MUD; and

FIG. 16 is a block diagram of a simplified electronic device capable ofbeing used with the methods and systems herein according to oneembodiment.

DETAILED DESCRIPTION OF THE DRAWINGS

The present disclosure provides a method at a network element forconfiguration for Internet of Things (IoT) devices using manufacturerusage description (MUD) files, the method comprising: receiving at leastone MUD Uniform Resource Locator (URL) from an IoT Device; sending, fromthe network element to at least one MUD Server based on the MUD URL, aUniform Resource Indicator; responsive to the sending, receiving aplurality of MUD files from the MUD server; creating a plurality ofpolicies from the plurality of MUD files, the plurality of policiescorresponding to a normal mode of operation and a secondary mode ofoperation; and forwarding the plurality of policies to a gateway fromthe network element.

The present disclosure further provides a network element forconfiguration for Internet of Things (IoT) devices using manufacturerusage description (MUD) files, the network element comprising: aprocessor; and a communications subsystem, wherein the network elementis configured to: receive at least one MUD Uniform Resource Locator(URL) from an IoT Device; send to at least one MUD Server based on theMUD URL a Uniform Resource Indicator; responsive to sending the UniformResource Indicator, receive a plurality of MUD files from the MUDserver; create a plurality of policies from the plurality of MUD files,the plurality of policies corresponding to a normal mode of operationand a secondary mode of operation; and forward the plurality of policiesto a gateway from the network element.

The present disclosure further provides a computer readable medium forstoring instruction code for configuration for Internet of Things (IoT)devices using manufacturer usage description (MUD) files, which whenexecuted by a processor of a network element cause the network elementto: receive at least one MUD Uniform Resource Locator (URL) from an IoTDevice; send to at least one MUD Server based on the MUD URL a UniformResource Indicator; responsive to sending the Uniform ResourceIndicator, receive a plurality of MUD files from the MUD server; createa plurality of policies from the plurality of MUD files, the pluralityof policies corresponding to a normal mode of operation and a secondarymode of operation; and forward the plurality of policies to a gatewayfrom the network element.

The present disclosure therefore provides embodiments to allow Class 2IoT devices to be able to directly communicate with emergency servicesduring an emergency event. In accordance with the present disclosure,“direct communication” implies Internet Protocol (IP) level routingbetween Class 2 IoT devices and emergency services servers or devices,that bypasses regular (“normal mode of operation”) communicationsservers and/or gateways.

As described below, one option for communications would be through anemergency clearinghouse. However, the clearinghouse server may bephysically located far from the actual emergency and needs to rely onaccurate location information to be able to distribute the data to anappropriate emergency response system. It is also a single point offailure.

Further, in some cases, requirements and/or architecture designs may beimposed that IoT devices need to call emergency services servers orPublic Safety Access Points (PSAPs) directly. Specifically, it may bedesirable to minimize processing load and delays at the applicationserver side, which has to receive data and send it to the emergencyservices.

Furthermore, a cybersecurity requirement may exist for the such Class 2devices, which may be a requirement for “need-based communication”. Inparticular, “need-based communication” implies that such directcommunication should be precluded during normal operation but allowedduring an emergency and disallowed once the emergency ends. This may bedone in order to minimize security concerns including an attackerattempting to extract IoT device data in an unauthorized fashion, forexample by impersonating or spoofing an emergency services server. Thismay be further done to avoid attackers attempting to take control of IoTdevices and use them to mount a (Distributed) Denial of Service ((D)DoS)attack against a local emergency service server or PSAP.

Constraining communication is typically done via firewall rules that areinstantiated on network nodes such as gateways. A permanently open“pinhole” allowing communication with the emergency services at alltimes would constitute an additional attack vector.

Therefore, in accordance with the embodiments of the present disclosure,methods and systems are provided to enable need-based, directcommunications between Class 2 IoT devices, such as sensors andactuators, and a (local) emergency service during an emergency event. Todo this, an IoT device can be designed or configured to operatedifferently in the case of an emergency, for example by changingcommunication end points or protocols, or changing the access controlpolicy in force at the device or its gateway to allow access to itscollected data by first responders or similar entities, or to takecommands from first responders or similar entities.

Example Device Use in Emergency Communication

IoT devices are deployed in many verticals, including but not limitedto, smart buildings or homes, utilities, healthcare, in vehicles, amongother examples. Such IoT devices communicate by taking input from, orsending information to, another node in the network.

An IoT device's behavior and pattern of communication may change toadapt to the case of abnormal conditions in the area where it isdeployed. For example, such abnormal condition may be an emergency or adisaster situation.

The International Standards Organization/International ElectrotechnicalCommission (ISO/IEC) has a reference IoT architecture defined in IECISO/IEC JTC1/SC 41 30141 “Information technology—Internet of ThingsReference Architecture (IoT RA)”. This architecture contains a use casefor an emergency situation in a building, where the doors are unlockedwithout further access control. For example, this architecturespecifies:

-   -   “In cases of an emergency like a fire, the arrival of the fire        service requires that the doors to a building be unlocked. The        security policy that governs the doors' access can be enhanced        with context. The context here is that the building is currently        experiencing an emergency situation and that the emergency        services are in the vicinity. Based on these two contextual        inputs the policy could enable the system to unlock the door        automatically and provide access without the need for further        authorization.”

Other examples exist to define the behavior of IoT devices in differentcontexts.

In a first example, the European Network and Information Security Agency(ENISA), in their document “Baseline Security Recommendations for IoT inthe context of Critical Information Infrastructures”, November 2017,recommends to “[GP-TM-30]: Ensure a context-based security and privacythat reflects different levels of importance (e.g. emergency crisis,home automation)”. One interpretation is that the security/privacycharacteristics should be different for an emergency state vs. normalstate.

In a second example, the US Department of Homeland Security, in their“Strategic principles for securing IoT”, November 2016 document,recommend to “Build in controls to allow manufacturers, serviceproviders, and consumers to disable network connections or specificports when needed or desired to enable selective connectivity.” One wayto interpret the selective connectivity enablement could be that whentelemetry data exceeds a certain threshold, it can be assumed to be inan incident, and so it can attempt to connect to/accept incomingconnections from other entities (e.g. peers) not normally allowed.

In a third example, oneM2M in their TR-0001 V2.4.1, “Use CasesCollection” document, include several scenarios where the behavior ofIoT devices is altered upon an emergency situation. A first concernsEnterprise: Smart Building, in which, when an emergency situationoccurs, devices behave differently e.g. doors unlock, sirens aretriggered, etc. A second involves Healthcare: Secure remote patient careand monitoring, in which, when an emergency situation occurs, emergencyresponders can be called upon. A third concerns Public services: Streetlight automation, where the luminosity of a streetlamp can be changedwhen an emergency vehicle is detected to be within a certain proximitye.g. via a proximity sensor, from a server, from other street furniture(e.g. traffic lights).

In a fourth example, the European Telecommunications Standards Institute(ETSI) provides a document TR-103 582, “EMTEL; Study of use cases andcommunications involving IoT devices in provision of emergencysituations”, July 2019. This document contains several scenarios withIoT in emergency situations. In a first scenario, an IoT device may makea direct emergency call. In a second scenario, an IoT service platformoperator may make an emergency call based on the data it receives fromthe IoT device. Such call may include additional data from the device.In a third scenario, emergency services teams may access pre-deployedIoT devices that they do not normally have access to. Potential conflictis flagged as two entities (building management and emergency teams)both have access to a device, at the service level (not thenetwork/transport level). This third scenario points to a change inaccess control policy.

Clearinghouse

In one use case, emergency service teams may access pre-deployed IoTdevices control or data. An emergency service team may comprise membersmanaging and coordinating the emergency service operations, and mayinclude members of an emergency mission in or near the incident area.Examples include first responders such as fire crew, police officers,technical and medical staff, among others. For example, reference is nowmade to FIG. 1 . In the embodiment of FIG. 1 , IoT devices such as amobile phone 112, an alarm system 114, a temperature monitoring system116, a video camera 118, among other options for IoT devices maycommunicate through an access point 120 with an IoT network 122. The IoTnetwork 122 can be a long-range or short-range wireless network or awired network. In this case, the IoT service platform 130, along withthe IoT devices, may be pre-deployed to communicate with an emergencyservices decision-maker 140. Thus, in an emergency in a private orpublic building or in an area with a pre-deployed IoT based safetysystem, IoT devices and the building safety system can provideadditional helpful information to emergency service teams.

As used herein, a clearinghouse is a standards compliant LocationInformation Server (LIS) and an Additional Data Repository (ADR) that isaccessible to emergency personnel through a portal or throughintegration with a PSAP's existing equipment and software. One exampleof such clearinghouse is the RapidSOS Clearinghouse, as for exampledescribed in RapidSOS—Karen Marquez “RapidSOS Clearinghouse”, April2019.

Further, an IoT service platform is an intelligent layer betweenapplications, networks and IoT devices. It is a coherent set ofstandardized functionalities. An IoT service platform is considered asan enabler for communication and data interoperability, as provided inETSI TR 103 582. In some cases, the IoT service platform can include anIoT App server.

Manufacturer Usage Description

A Manufacturer Usage Description (MUD) system consists of anarchitecture and data format defined by the Internet Engineering TaskForce (IETF) that allows and places responsibilities on IoT devicemakers to specify the intended communication patterns for their deviceswhen such devices connect to a network. For example, this architectureand data format is defined in IETF RFC 8520, “Manufacturer UsageDescription Specification”, March 2019. A network where such a device ismade part of can then use this intent to write an access policy for thenetwork's context, and thus enforce how the device functions. Thismechanism is expected to reduce security incidents related tocommunication, protecting the device from external threats, rather thantrying to protect the network from the device.

An IoT device is expected to have a very small number of uses, and so itshould have a small number of communication patterns. Thus, by providingan intent, the approach is traceable/scalable. Further, it is assumedthat the manufacturer is in the best position to say what is normalcommunication that should be allowed for the device, assuming any otherpattern of communication is to be disallowed.

A network administrator may then be able to write a local policy basedon a MUD file utilizing a logical entity entitled a “MUD manager”. TheMUD manager is a tool and functional block that acts under the directionof the system administrator. The MUD manager may query the administratorfor permission to add an Internet of Things “thing” and associatedpolicy that should be applied to this device. Therefore, the MUD manageris a logical component. Physically, the functionality that the MUDmanager provides can and often is combined with that of the networkrouter in a single network device.

As used herein, a “policy” includes rules that govern the management ofa network of nodes, encompassing treatment (e.g., allowed or dropped) oftraffic to and from entities inside or outside that network. In thecontext of MUD, the switch/router implements an IPaccess-control-list-based policy using DNS names. Such policy is not theMUD file. The policy is “written” by the local deployment network (orIoT service platform) based on the information in the retrieved MUDfile.

According to IETF RFC 8520, MUD consists of three architectural buildingblocks. A first is a Uniform Resource Locator (URL) that can be used tolocate a description file. A second is the description itself, includinghow it is to be interpreted. A third is a means for local networkmanagement systems to retrieve the description.

The URL serves both to classify the device type, for example in the casewhere the decision to allow a device to join the local network is basedon the device type and not a unique device identifier, and to provide ameans to locate an access rules description file. The manufacturer ortype itself may be indicated simply by the authority component, such asthe domain name, of the MUD URL. The MUD URL can be sent or “emitted” bythe thing (IoT device) in at least three ways. In a first way, the MUDURL can be sent via the Dynamic Host Configuration Protocol (DHCP) in aDHCP Option. In a second way, the MUD URL can be sent via a Link LayerDiscovery Protocol (LLDP). In a third way, the MUD URL may be sent via amessage using the IEEE 802.1AR or 802.1X standard to embed the MUD URLin an X.509 certificate extension, for example for IEEE 802.1Xauthentication messages.

MUD access rules in the MUD file description defined by the manufacturercan cover various scenarios, including but not limited to, communicatingthrough the cloud, for example, to a given application server in the IoTservice platform in one case. In another case, the MUD file may includerules for communicating to other devices of the same manufacturer withinthe local deployment. Other options are possible.

Specific protocols and port numbers can also be specified for each ofthese communications. The focus is on network access control. However,these rules can be expanded to other areas including quality of service.

Reference is now made to FIG. 2 , which shows an example MUDarchitecture as in IETF RFC 8520. In the example of FIG. 2 , the MUDarchitecture and format allow for automating the definition of a networkaccess policy based on the MUD profile defined by the manufacturer.Methods to instantiate these profiles depend on the network domain wherethe device is deployed.

In the specification, the MUD file format uses the Yet Another NextGeneration (YANG) for format and JavaScript Object Notation (JSON) forserialization.

A translation approach between the Access Control Lists (ACL) in the MUDfile and the local policy ready for a router/switch/gateway to enforceis not specified in the IETF RFC. Examples of access control entries ina policy include firewall rules, flow rules, among others. These rulesare to limit the traffic between the device (Thing) and external domainsor between the device (Thing) and other devices in the Local Network.

Thus, in the example of FIG. 2 , an End System Network 210 (or local IoTdeployment network) includes the Thing 220. The Thing 220 emits a URL,for example as described above. The URL can be configured in the Thing220 (or IoT device) by the device manufacturer.

A router or switch 222 extracts from the protocol frame a URL. The URLis then forwarded to MUD manager 224.

The MUD manager 224 retrieves the MUD file and signature from the MUDFile Server 230, assuming it does not already have a copy. MUD manager224 validates the signature and tests the URL.

The MUD manager 224 may query an administrator for permission to add theThing 220 and associated policy. If the Thing is known or the Thing typeis known, the MUD manager 224 may skip this step.

The MUD manager 224 instantiates a local configuration based on theabstractions defined in the RFC.

The MUD manager 224 configures the switch nearest the Thing 220. Othersystems may be configured as well.

When the Thing 220 disconnects, the policy may be removed.

In the example of FIG. 2 , a human such as the administrator of a domainmay be involved in reading the MUD file and writing the policy to beenforced at the network device.

Similarly, FIG. 3 depicts MUD policy retrieval. In the example of FIG. 3, IoT devices 310 are shown to include an alarm 312, a camera 314, athermostat 316 and a mobile device 318. However, these are merelyprovided as examples and other examples of IoT devices 310 are possible.

In an example implantation in the art, referring to FIG. 3 , one of IoTdevices 310 send a MUD URL to network devices 320, which may includerouters, gateways or switches, among other options. The MUD URL is thenforwarded to the MUD controller 330, which is the same as the MUDmanager 224 from FIG. 2 . The MUD controller 330 may then use the MUDFile Server 340 to request and receive the policy files. In some cases,the MUD controller 330 may then send back a policy, such as an accesscontrol list, to network devices 320.

In another example, MUD may be used with certificates. This is a moresecure way for a device to convey its configuration and MUD filelocation, but is more costly to implement as with any digitalcertificate that can come configured as part of an IoT device.

For example, an X.509 certificate that is embedded in the IoT device canhave an extension such as “ext-MUDURL” to contain the URL that points tothe online MUD description that is valid for the device holding thecertificate. Another certificate extension may be defined as“ext-MUDsigner” to identify the server or subject field of the signingcertificate of the MUD file.

For example, the National Institute of Standards and Technology (NIST)has outlined a proof of concept using off-the-shelf IoT and networkboxes, called NIST-MUD to show the feasibility of MUD and published thisas NIST SP 1800-15B “Securing Small-Business and Home Internet of Things(IoT) Devices; Mitigating Network-Based Attacks Using Manufacturer UsageDescription (MUD)”, November 2019. FIGS. 2.4-4 of this publication isshown with regard to FIG. 4 of the present disclosure.

In the embodiment of FIG. 4 , IoT Device 410 communicates with a router411. Router 411 includes a router firewall 412, a router DHCP server414, a router MUD manager 415, and a router database 416.

Further, the cloud 418 includes a MUD file server 419.

As shown at block 420, the device 410 is connected to a network (e.g., awired or wireless network). Thereafter, a DHCP DISCOVER message 430 maybe sent to the DHCP server 414. The DHCP DISCOVER message 430 includes aMUD URL.

The DHCP server 414 may send a DHCP OFFER message 432 back to the device410. Further, device 410 may send a DHCP REQUEST message 434 to therouter DHCP server 414 and the DHCP server 414 may send a DHCP ACKmessage 436 that includes an assigned IP address back to the IoT device410.

After receiving the DHCP discover message 430, the router DHCP server414 may send the MUD URL in message 440 to the router MUD manager 415.The router MUD manager 415 may then register the device's Medium AccessControl (MAC) and MUD URL using message 450 to the router database 416.

Further, the router MUD manager 415 may send an https GET MUD filemessage 460 to the MUD file server 419.

In response, the MUD file server 419 may send the MUD file back to therouter MUD manager 415 in message 462.

Thereafter, the router MUD manager 415 may send an https GET MUDsignature file message 470 to the MUD file server 419 and in responsereceive the MUD signature file in message 472.

Once message 472 is received, the router MUD manager 415 may verify atthe MUD file with the signature file at block 474. Assuming suchverification is successful, then the router MUD manager 415 may sendfirewall rules in message 480 to the router firewall 412. The firewallrules are a set of policies based on the information in the MUD file.

Thereafter, the router firewall 412 may install firewall rules from theMUD file as shown at block 482.

Bootstrapping Remote Key Infrastructure (BRSKI)

The Automatic Networking Integrated Model and Approach (ANIMA) workinggroup of the IETF is developing a standard around the BootstrappingRemote Secure Key Infrastructure (BRSKI), namely the “IETF Draftdraft-ietf- anima-bootstrapping-keyinfra-38: Bootstrapping Remote SecureKey Infrastructures (BRSKI)”, March 2020. The BRSKI standard outlinesmeans to automatically deploy identity to devices so that they can beauthorized on the network and establish secure communications. Thisenables zero-touch provisioning of devices, suitable for industrial IoTand smart home scenarios.

Entities involved include the: Pledge (a term denoting device/client),Switch/router, Registrar (all in the local domain), Manufacturer withManufacturer Authorized Signing Authority (MASA) and optional Ownershiptracker in the Original Equipment Manufacturer (OEM) domain.

BRSKI requires an Authentication, Authorization and Accounting (AAA)infrastructure, which in some cases can be combined with the Registrarfunction. The security characteristics include the use of X.509certificates and Transport Layer Security (TLS) during authenticationand authorization involving all parties.

With BRSKI, a device asks for a voucher from its trusted manufacturer.The Registrar forwards that voucher request, obtains a voucher, andsends the voucher to the device for verification. The voucher is in astandardized format and contains claims made by the manufacturer aboutthe device and the local deployment.

At the end of the procedure, the device trusts the local domain (orlocal IoT deployment network) and the local domain trusts the device.

In particular, reference is now made to FIG. 5 . In the example of FIG.5 , a device 510 may establish a provisional TLS connection 520 with theregistrar 512.

The device 510 may send a voucher request 530 to registrar 512.Registrar 512 may then forward the voucher request in message 532 to theMASA 514.

The voucher may be then provided in message 534 back to registrar 512.Registrar 512 may then forward the voucher in message 536 back to device510.

The process may then involve the verification of the TLS connection asshown by arrow 540 and the downloading of additional certificateauthorities as shown by arrow 550.

At arrow 560, the enrolment is established using the protocol“Enrollment over Secure Transport”, as defined by IETF RFC 7030.

Using BRSKI and MUD to Configure Device and Router

In some cases, it is possible to use both BRSKI and MUD to configure thedevice and the switch, one after the other. Reference is now made toFIG. 6 . In the example of FIG. 6 , an IoT device 610 communicates witha local domain 611 which includes a switch 612, a registrar/AAA 614 anda MUD manager 615.

Further, OEM domain 616 includes MASA 617 and MUD server 618.

The IoT device 610 may first configure the device trust utilizing theBRSKI procedures described above with regard to FIG. 5 , as shown atarrow 620. After 620, a trust relationship is established between theIoT device 610 and the local domain 611.

Subsequently, the switch 612 may be configured based on the MUD as forexample outlined in FIGS. 2 and 3 above and shown in the embodiment ofFIG. 6 with arrow 630. After 630, the local domain 611 has the MUD fileand the switch can be configured with the policy based on the MUD file.

In other examples, BRSKI and MUD may be used together to configure boththe IoT device and the router/switch. Reference is now made to FIG. 7 .

In the example of FIG. 7 , IoT device 710 can communicate with localdomain 711, which includes switch 712, registrar/AAA 714 and MUD manager715.

Further, OEM domain 716 includes MASA 717 and MUD server 718.

In the example of FIG. 7 , the configuring the device trust utilizingthe BRSKI procedure is shown with arrow 720 and includes the configuringof the switch utilizing MUD as shown with arrow 730.

Aspect: Modifications to the MUD System

Based on the above, MUD and its associated protocols is a commonly usedmethod to configure networks to support IoT devices in accordance withthe vision of the OEM for that device. BRSKI is an IETF-defined way toautomate bootstrapping of a local-domain key infrastructure based onmanufacturer installed device certificates and root of trust. Both areused in the task of configuring an IoT device upon onboarding.

However, these protocols do not define how to configure a switch/routerand the firewall therein to support an IOT device that that has both anormal mode of communication and a secondary (e.g. emergency/anomaly)mode of operation. Further, no trigger is defined for changing theconfiguration from the normal to the secondary mode of operation andvice-versa, nor how such trigger should be signaled and what entitydecides whether the trigger is satisfied.

Further, the protocols do not define how the system determines theaddress of the appropriate communication end point for use duringemergencies. Specifically, in some cases, the URL or the Fully QualifiedDomain Name (FQDN) of the secondary server relevant to the IoT devicelocation may not be known in advance at the OEM side.

Therefore, in accordance with the embodiments of the present disclosure,an architecture having three domains is provided in the example of FIG.8 . The flow diagram shown in FIG. 8 involves three domains, namely alocal domain where the IoT device is deployed, the IoT OEM domain, andthe secondary services domain, referred to in this example as theSecondary Server Domain.

Specifically, referring to FIG. 8 , an IoT device 810 communicateswithin a local domain 811. The local domain 811 includes a switch 812,on top of which an application 814 and a potential trigger 815 mayexist. In some cases, the switch application 814 can determine whetherthe trigger 815 is met so that the switch 812 can change to a differentpolicy.

The local domain 811 further includes a MUD manager 816, which mayinteract with a server lookup function 817. For example, the serverlookup function 817 may involve a look up to find the local emergencyservices network. However, in other cases, rather than emergencyservices, the present disclosure could deal with other anomalies orsituations where in IoT device has a primary mode of operation and asecondary mode of operation. In this case, server lookup 817 may involvelooking up which server to communicate with during the IoT device'ssecondary mode of operation.

Further, local domain 811 may include an IoT App server 818, which mayfurther include a trigger 819 that indicates conditions to switch from aprimary mode of operation to a secondary mode of operation (and possiblyalso back to the primary mode, in the same or a different trigger).

The second domain is the IoT OEM domain 820, which may include a MUDserver 822.

The third domain is the Secondary Server domain 824 which may includethe secondary server 826. For example, the Secondary Server domain 824may be an emergency server domain. However, in other cases where the IoTdevice is operating in two modes, the Secondary Server domain 824 may beany other server to which communication may exist while the IoT deviceis operating in its second mode.

There are two phases in the IoT device life. A first phase is aconfiguration phase and a second phase is an operational phase.

During the configuration phase, the IoT device 810 may send a MUD URL inmessage 830 to the MUD manager 816.

MUD manager 816 may then provide a Uniform Resource Identifier (URI) tothe OEM domain 820 MUD server 822, as shown by message 832.

In response to receiving message 832, the MUD server 822 may provide theMUD file, which may include a trigger to indicate mode of operationchange, in message 834, back to the MUD manager 816. The trigger caninclude one or more conditions for triggering the operation mode change.

The MUD manager 816 may provide/write both regular and secondary (e.g.anomaly or emergency) policies based on the MUD file(s) that werereceived in message 834 to the switch 812, as shown by message 840. Theswitch 812 can store both regular and secondary policies received inmessage 840.

Further, the trigger received in message 834, which could be part of orbased on the MUD file, may be provided to the IoT App server 818 withinmessage 842. In some cases, the trigger received in message 834 can alsobe provided to the switch 812.

In the embodiment of FIG. 8 , an identifier, network address or locationfor the emergency network or other secondary operation handling networkmay be provided back to the IoT device 810 as part of message 844 fromMUD manager 816. The MUD manager may have obtained this information fromthe Server lookup function 817. The identifier, network address orlocation for the emergency network or other secondary operation handlingnetwork may also be provided to the switch 812.

At this point, the configuration phase for the setting up of the IoTdevice 810 is finished.

During the operational stage, the IoT device 810 may provide normal dataflow, depicted by arrow 850, to the IoT application server 818 via theswitch 812 applying the regular policy.

In some cases, the secondary server 826 detects an emergency or ansecondary condition, and signals this in message 860 to the IoT Appserver 818. For example, the message 860 can include emergencyindications (such as a 911 call indication) from sources other than IoTdevices 810. The secondary condition 860 may include a request for theIoT App server 818 to enable the data from IoT device 810 to flowdirectly to the secondary server domain 824, possibly bypassing the IoTApp server 818.

Based on the trigger information received in message 842, the IoT Appserver 818 may make a decision on whether the trigger conditions are metbased on data 850 received from the IoT device 810, other emergencyindications such as a 911 call indication received in message 860, orboth, as shown at block 862.

If one or more of the trigger conditions are found to be met at block862, then the IoT App server 818 may send a command to start secondarydataflow message 864 to the IoT device 810.

Further, the IoT App server 818 may send a message to the switch 812 toopen the secondary communication ports, as shown by message 866. Themessage 866 can indicate to the switch 812 to use the secondary policy.

Thereafter, since the trigger conditions were met and the secondarycommunication ports are open, emergency or secondary data may flow fromthe IoT device 810, via the switch 812 applying the secondary policy, tothe secondary server 826, possibly bypassing the IoT App Sever 818, asdepicted by arrow 870 in the embodiment of FIG. 8 . In some cases, thesecondary data can flow to both the IoT App server 818 and the secondaryserver 826.

Therefore, the embodiment of FIG. 8 provides for a policy that isenforced at a network device such as a switch of an IoT device localdomain, which allows direct communication between the IoT device and ansecondary services endpoint during a secondary state such as a state ofemergency. For example, the direct communication is enabled between theIoT device 810 and the secondary server 826 without necessarily passingthe data through the IoT App server 818.

Once the emergency or secondary operation condition has expired, thesystem may transition back into the normal data flow. This may involveproviding a trigger condition back to the IoT App server 818, which maythen send a command to resume normal data flow to the IoT device 810 andalso a command to close the emergency or secondary communication portsto switch 812. Similar to the decision making at block 862, the decisionto transition back to the normal operation can be based on indicationsfrom secondary server domain 824 (e.g., an indication of ending of theemergency situation), data from the IoT device 810, or both. In othercases, the emergency or secondary operation condition may be timelimited and on expiration of such time, the IoT App server maytransition the local domain and IoT device 810 back to normal data flow.Other options are possible.

Therefore, the embodiments described herein provide a solution whichcovers the case when a change in the allowable communication pattern isneeded at the switch or router for an emergency or secondary operationsituation that an IoT device finds itself in.

In accordance with the embodiments described herein, MUD is extended ormodified to support two or more profiles or policies for an IoT or othersuch device. For example, a normal-use profile and an emergency profilemay be two types of profiles. The embodiments herein provide solutionsfor devices meant to communicate via a network router, switch or gatewayand a MUD manager. For this purpose, MUD is extended or modifiedcompared to the currently defined implementations for MUD.

In a first aspect of the embodiments described herein, challenges existon how to configure a switch or router and a firewall that are tosupport an IoT device that has both a normal mode of communication and asecondary mode of communication. In accordance with the embodiments ofthe present disclosure, an IoT device may have two distinct associatedMUD files relevant to it, and the way this fact is signaled, and thesecondary configuration obtained, is one aspect of the presentdisclosure.

In a first case, a second (and optionally a third, fourth, etc.) URL isadded to be emitted by a device, in addition to the normal MUD URL. Forexample, such URLs may be carried in another extension in thecertificate of the IoT device as configured by a manufacturer, or inanother DHCP extension, or in another LLDP one sent by the device. Eachadditional URL points to the location of a file that specifies thesecondary device behavior, where such behavior is to be specified bysome other server than the MUD Server. Such other server is pointed toby the second (or third, fourth, etc.) URL, that is, the server hoststhe file specifying the secondary behavior of the device.

Alternatively, if certificates are used, then the manufacturercertificate may indicate in a new field the existence of a special MUDfile for secondary contexts, rather than an actual URL. In this case,the MUD manager must find other means to locate this special MUD file.

Reference is now made to FIG. 9 , which shows a flow for obtainingmultiple policies at a router or gateway. In the embodiment of FIG. 9 ,IoT device 910 communicates with a router or gateway 912. Further, therouter or gateway 912 may communicate with a MUD manager 914.

In the example of FIG. 9 , a plurality of MUD servers, referred to inthe example of FIG. 9 as MUD server 916 and MUD server 918, may providedifferent MUD files for the different operational contexts. These twoservers may be combined in the same physical network node, or combinedlogically but be physically separate.

Specifically, as shown by arrow 920, IoT device 910 emits the regularMUD URL. A second MUD URL, depicted in arrow 922, is also emitted by theIoT device 910. The emission may be done, for example, via extensions toDHCP, LLDP, or X.509 certificates as described above and as used inrespective protocols between the IoT device 910 and the router orgateway 912. This is shown with arrow 924 in the example of FIG. 9 . Theemitting may be done in various ways. For example, it may be done at anapplication layer in some cases. In other cases, it might be done via QRcodes. In other cases, the emitting may be performed as printed in amanual and may be manually entered via smartphone or directly into therouter or gateway interface, among other options. In such cases, asmartphone may then connect to the gateway so that the gateway gets theMUD URLs.

The router or gateway 912 may forward the two URLs to MUD manager 1314,as shown with arrows 930.

The MUD manager 914, for example using an HTTPS GET request, may sendsuch request to the MUD URL, as shown with arrow 940. This is similar toexisting procedures to obtain a MUD file.

In response, MUD server 916 sends back a MUD file, as shown with arrow942.

In an aspect, the MUD manager 914 further has the second additional URLfor the secondary (e.g. emergency) context and can use such URL to fetcha MUD file from the server pointed to by the URL. For example, as shownby arrow 950, an HTTPS GET request may be sent to MUD server 918, and inresponse the secondary MUD file is received from MUD server 1318, asshown by arrow 952. In some cases, the MUD server 918 may be the same asMUD server 916. In other cases, the two servers may be differentservers.

On receiving the MUD file as shown at arrow 942, the MUD manager 914constructs a normal context policy as currently performed. Further, onreceiving the secondary MUD file, as shown at arrow 952, the MUD manager914 writes a policy for the secondary context. For example, this may bean emergency context, where an emergency context includes theenvironment conditions, parameters, and state of play during a case ofemergency, from the point of view of an IoT device.

The MUD manager 914 sends the first policy, as shown by arrow 960, tothe router or gateway 912. Further, the MUD manager 914 sends the secondpolicy, optionally along with the trigger, to the router or gateway 912,as shown with arrow 962.

Therefore, in accordance with the embodiment of FIG. 9 , two URLs areprovided, and two policies are returned to the router or gateway 912.

In a further embodiment, only one URL is used, and it is the MUD serverthat has knowledge that a secondary MUD file exists. The MUD server maysignal this information to the MUD manager when it returns the MUDfiles. Reference is now made to FIG. 10 .

In the embodiment of FIG. 10 , the secondary MUD file is downloaded fromthe same URL. That is, the MUD file server may return any or both of thetwo or more MUD files associated with the IoT device. In another option,the MUD file server may return a normal MUD file and an additionalredirect command to another MUD file server for the secondary usepolicy. For example, this may include returning a secondary URL for theMUD manager to obtain the second MUD file.

In the simplest context, a normal MUD file contains information for boththe primary and secondary use communication endpoints.

When there is no indication of a secondary MUD file from the device, theMUD manager may not know if there is a MUD file for emergencies orsecondary uses until the MUD server actually returns two files.

Therefore, in the example of FIG. 10 , IoT device 1010 communicates witha router, switch or gateway 1012. Further, the router or gateway 1012may communicate with the MUD manager 1014.

In the embodiment of FIG. 10 , a primary MUD server 1016, along with asecondary MUD server 1018, exist.

The IoT device 1010 in this case emits the normal MUD URL, as shown byarrow 1020, and as is currently done in the art.

The router or gateway 1012 forwards the received URL to the MUD manager1014, as is currently done in the art.

The MUD manager 1014, for example using an HTTPS GET request, may sendthe MUD URL. This is shown with arrow 1040, where the request is sent toMUD server 1016.

In response, the MUD manager 1014 receives a MUD file, as shown witharrow 1042. The MUD file returned may contain an extension to indicatethe parameters for secondary communication endpoints, or may contain aURL for obtaining a secondary use MUD file. Such URL may point to adifferent file (resource) on the same server or may point to a differentserver.

Alternatively, the MUD server sends, along with the original MUD file, asecond MUD file for the secondary use.

The example of FIG. 10 shows the case where the extension includes theURL for a second MUD server.

Therefore, in an optional step in FIG. 10 , the MUD manager 1014extracts the URL for the secondary MUD server 1018 and sends, forexample, an HTTP GET request to the secondary MUD server 1018, as shownwith arrow 1050.

In response, the MUD manager 1014 receives the secondary MUD file, shownwith arrow 1052. MUD server 1016 and MUD server 1018 may be the sameserver or may be different servers.

MUD manager 1014 may then construct a normal context policy as iscurrently done using the MUD file received at arrow 1042. The MUDmanager 1014 may also write a policy for the secondary context using theMUD file received at arrow 1052.

MUD manager 1014 may send the first policy to the router or gateway1012, as shown with arrow 1060. The MUD manager 1014 may further sendthe second policy and optionally a trigger, as shown at arrow 1062, tothe router or gateway 1012.

For both the embodiments of FIGS. 9 and 10 , a given MUD file serverhosts the MUD file for secondary policies. The same MUD file server canbe used for the normal use MUD files, for example for all types of IoTdevices, or for devices from a given manufacturer, among other options.In other cases, the normal MUD file could come from a different MUD fileserver.

Triggers

The MUD file for the secondary context can contain a new element toindicate the trigger that is expected to make the IoT device changepolicies, from a manufacturer point of view. For example, such newelement may be referred to as a “secondary-trigger” or an“emergency-trigger”, among other options.

For example, for a temperature sensor, the trigger may be any reading of140 degrees Fahrenheit (60 degrees Celsius) or higher.

A trigger may have a condition to transition into the secondary stateand may further in some cases have a condition to transition back to theprimary or normal state. The conditions may be the same or may bedifferent. For example, in some cases, the temperature sensor may needto have a reading below 122 degrees Fahrenheit (50 degrees Celsius) torevert to the normal state.

Regarding such trigger, the trigger may have a Trigger element syntax.This trigger may be use-case specific, and thus the element itself inthe MUD file may be a string or some other type of defined node/elementthat allows for flexibility in the expression of this trigger. In somecases, such string may be human-readable.

As an example, an element with the same syntax as an element called“systeminfo” of the IETF MUD file could be used for the trigger. Both ofthese, along with other information, are meant for human user(administrator) consumption. Such other information may include, forexample, whether the device is still supported by the manufacturer ornot, among other information.

These fields are common to many devices, for example all sensors of type“X” in an industrial IoT scenario, so the decision to accept this typeof IoT device onto the network can be done once per device type andadditional device acceptance can be automated, as described below.

In some cases, the trigger element can be incorporated in thesecondary-use policy that the switch, router or gateway can enforce oncea secondary mode of operation (e.g. a state of emergency) is declared.

Further, to allow for the network administrator, such as thosesupporting a building management system, to also have control over thetrigger setting, the trigger threshold setting received in thesecondary-use MUD file can, in some cases, be augmented or overriddenwhen producing a secondary policy written by the network administrator.This therefore allows for local domain control.

For example, a manufacturer may indicate that a state of emergency forits thermometer exists when a reading is above 140 degrees Fahrenheit(60 degrees Celsius). But the network administrator in the localdeployment may override that to be 130 degrees Fahrenheit (54 degreesCelsius), since the facility where this IoT device is deployed isclimate controlled. In other cases, the network administrator mayspecify that even a reading of 130 degrees Fahrenheit is not sufficient,but some other condition must be met. For example, the temperature muststay at the threshold level for 15 minutes, among other options.

As provided in FIG. 8, 9 or 10 , the MUD Manager, once it has obtainedthe trigger from the MUD file, or via other means, could inform the IoTplatform server of the trigger for that device. This protocol may beapplication specific.

In other cases, the IoT device may be configured to know what thetrigger is, and may be able to act when the trigger threshold is met,for example to connect to a different endpoint (the emergency responseserver), and send data to the endpoint that is either the same (as innormal use) or different. In addition, or alternatively, the IoT devicemay take input (application-layer commands) from that endpoint.

Alternatively, the IoT device may not be aware of the trigger but cantake application-layer commands from the IoT service platform to senddata to a different endpoint.

Deciding a trigger is met can be done by the IoT device itself, by theRouter, gateway or switch in some cases, and/or by the IoT platformserver (e.g. IoT App server 818 from FIG. 8 ). If the decision isperformed at the router, gateway, switch or server, that entity may needto not only know what the trigger is, but also include application-layerlogic to be able to process the data from the device, and decide whetherit warrants the declaration of an emergency/secondary condition, andtherefore a policy change. In the case of the IoT platform server, thedecision that there is an emergency/secondary situation mayalternatively be taken independently of any IoT device data, such as butnot limited to a 911 or 112 call indication from the secondary serverdomain 824 or other human-sourced information, or based on both externalinput and data from one or more IoT device.

IoT Platform Server Decides the Trigger Condition is Met

Therefore, in accordance with one embodiment, the IoT platform server(or IoT App server) decides that the trigger condition is met, and theninforms the device and switch. This decision may be based on the data itreceives from the IoT Device and/or on other data.

In this case, the trigger condition being met is decided at the IoTservice platform server. This may limit the attacks whereby a device iscontrolled by an attacker to cause a state of emergency or othersecondary state, and a policy change, or any other actions that such astate may bring about.

In particular, reference is now made to FIG. 11 , which shows a flowdiagram between an IoT device 1110, switch 1112 and an IoT applicationserver 1114, also referred to herein as the IoT service platform server.

In this case, the IoT application server 1114 may have information abouta trigger 1116 for an emergency/secondary situation.

During normal operation, normal data flow, as shown with arrow 1120,occurs between the IoT device 1110 and the IoT application server 1114.

The IoT application server 1114 can determine when an emergencysituation or secondary situation can be declared, as shown with block1130.

Once an emergency or secondary situation is declared, the IoTapplication server 1114 can send a message 1140 to IoT devicesrequesting that they switch policies. Switching policies allowsadditional or different destination addresses and ports for datacommunication. In the embodiment of FIG. 11 , message 1140 is shown tothe start emergency data flow. However, in other cases, the message maybe to start secondary condition data flow. In other cases, the messagemay be to resume normal data flow if the trigger at block 1130 is atrigger to resume the normal conditions. Other options exist.

The IoT application server 1114 can also send a message 1150 to theaffected routers/gateways to switch over the policy. This is similar tomessage 866 from FIG. 8 . A switch 1112 may be asked to change policiesfor all of its devices even if none of the devices it services actuallyhad met the trigger threshold condition.

The IoT devices whose policy needs to change may be just the device thattriggered it, or it may include other devices under the gateway/router.

To avoid a race condition, the IoT device 1110 should not switchpolicies without the router having switched policy. If the IoTapplication server 1114 commands the policy change, then the IoTapplication server 1114 may need to inform both the router (switch 1112)and the IoT device 1110, so that the router does not drop the packetsthe IoT device 1110 intended to send to the emergency/secondary server.This might, for example, be achieved by including a ‘time of activation’within the messages that are sent to the IoT device 1110 and the switch1112, where the ‘time of activation’ indicates the time at which bothshould start applying the new policy.

In one example of how an IoT application server 1114 can cause a switch1112 to change policies, the firewall vendor can make an ApplicationProgram Interface (API) available to the firewall configurationapplication running on the switch 1112 and in a server (e.g., the IoTApp server 1114). This API can be called by the IoT application server1114, which is running an IoT application.

The end result is that a new data pipe to the emergency communication orsecondary communication endpoint is instantiated at the IoT device 1110,as for example done at arrow 870 in the embodiment of FIG. 8 , and anupdate is additionally made to the access control list, including thefirewall, on the switch 1112. Once another trigger for the emergency isobtained at the IoT application server 1114, indicating theemergency/secondary context is no longer there, the policy may beswitched back to the normal-use for the affected devices and switches.In some cases, the access control list includes a set of IP addresses towhich the communication is allowed.

Application-Layer Logic on the Switch Decides the Trigger Condition isMet

In an alternative embodiment, application layer logic on the switch maydecide that the trigger condition is met, for example by interceptingdata from the device. The switch also informs the IoT platform serverthat the trigger condition has been met.

In particular, reference is now made to FIG. 12 , which shows a flowdiagram between an IoT device 1210, switch 1212 having application layerlogic 1214, and an IoT application server 1216, also referred to hereinas the IoT service platform server.

In this case, the switch 1212 may have information about a trigger 1218for an emergency/secondary situation.

During normal operation, normal data flow, as shown with arrow 1220,occurs between the IoT device 1210 and the IoT application server 1216.

If the trigger 1218 is enabled in the switch 1212, which occurs indeployments where the switch 1212 has application knowledge that enablesit to declare a state of emergency based on sensor data it receives fromthe device 1210, then the switch 1212 makes the decision that thetrigger is met at block 1230 and changes the policy, as shown by block1232 from a normal-use policy to the emergency/secondary use policy.

The switch 1212 can use application-layer signaling to inform the IoTdevice 1210 to change communication endpoints, as shown by message 1240.

The end result in this embodiment is that a new data pipe to theemergency/secondary communication endpoint is instantiated at the IoTdevice 1210. Once another trigger for the emergency is obtained,indicating the emergency/secondary context no longer exists, the policymay be switched back to the normal-use for this device.

Address of Appropriate Secondary/Emergency Endpoint

In a further embodiment of the present disclosure, a local deploymentdomain may find an appropriate emergency/secondary communicationserver(s) and adds that information to the ACL enforced at theswitch/router/gateway in the network where IoT device finds itself. Suchoperation could be done by a network administrator. The embodimentsdescribed below use an emergency situation for the secondary mode ofoperation. However, this is not limiting, and is provided forillustration only.

The local emergency/secondary server FQDN is used to update the ACL. Forexample, in the emergency case, at a high level, the switch/router ofthe IoT deployment looks up the Emergency Services IP Network (ESInet)FQDN and adds it to the ACL for its emergency-use policy. In some cases,this may require some level of application, specifically Domain NameSystem (DNS) protocol, awareness by the ACL enforcement entity on theswitch.

In a subsequent operation, the device may be informed about the ESInetso that it knows where to send data in case an emergency is declared.This operation can be done, for example, using an application-layermessage from application-layer logic on the router/switch or via anapplication-layer message from the IoT service platform server.

Various options exist for determining emergency services address (FQDNor IP address). In a first example, the emergency services address maybe determined at the local deployment domain. In a second example, theemergency services address may be determined at the OEM cloud or OEMdomain. After that, what is done with this information is describedabove with regards to FIG. 8 .

Therefore, in one aspect of the present embodiment, an entity orfunctional block is introduced that does lookup of local ESInet/PSAPbased on location, referred to as “ESInet Lookup function” or “ServerLookup” function. Such an entity can be deployed at the local domain(“on premise”) or at the OEM cloud, and the lookup can be done by anetwork administrator.

Specifically, emergency information, such as the PSAP and ESInet domainname including FQDNs, depends on the region or geographical area wherethe device is located. This information is retrieved at the manufacturersite, or at the deployment site, for example by a MUD Manager, a BRSKIRegistrar, or by a 3^(rd) entity.

Further, the FQDN/URL of the emergency server can be constructed by adevice or by a MUD manager using a potentially standardized method forconstructing the FQDN/URL. The constructed FQDN/URL may be customizedfor each geographical region, by for example inserting the country namefor that particular location into a character string with prescribedelements. This may be similar to an approach used in the ThirdGeneration Partnership Project (3GPP) wherein emergency numbers (asopposed to IP addresses) can be obtained via DNS query by using a FQDNconstruction that is defined in 3GPP TS 23.003, for example using astring of comma-separated-labels:“sos.en.epc.mcc<MCC>.visited-country.pub.3gppnetwork.org, where MCC isthe Mobile Country Code used in 3GPP telephony.

In a first case in the present embodiment, the emergency endpoint (orother secondary endpoint) server address information is determined atthe local deployment. In this case, the URL of the emergency MUD file,or the communication endpoints for emergency use to be used inconstructing an emergency policy, are not given in the normal process ofMUD provisioning. However, indications that such a policy existssomewhere may be already given, but the exact location (URI) of thisfile is not given. That is, the MUD Manager is left with the task tofind the emergency communication endpoint information from which to makea local policy.

In a second case of the present embodiment, emergency endpoint serveraddress information may be determined at the manufacturer domain. Inthis case, no MUD URL is used, but the OEM can return a MUD fileaugmented with the secondary endpoint information such as the ESInetand/or PSAP information for the local domain. The OEM finds out thelocal domain of the IoT in question using information piggybacked on themessages normally sent to the OEM server by the BRSKI Registrar or theMUD Manager in the process of bootstrapping or onboarding respectively.

Specifically, when BRSKI is used for bootstrapping a device, it enablesa local domain to securely configure the device with information andcredentials that the device can use in communications. MUD functionalitysimilarly provides mechanisms for making the corresponding configurationof switches/routers in the local domain. Since IoT devices andswitches/routers both need to be configured to support communications,it is possible that BRSKI (device configuration) functionality can beleveraged by MUD (router configuration) functionality and vice versa.Hence if a BRSKI Registrar determines the address of secondary serverssuch as the ESInet servers needed for configuration of the IoT device,then this information can also be made available to a MUD manager forconfiguration of the router and vice-versa.

In the above, the Local Emergency contact refers to locally relevantESInet server(s) and/or PSAP addresses, including IP address, URL,and/or SIP URI, among others. ESInets can range in locality from“local”, being a single PSAP, county, or small call center area, toregional, national, and international.

Both ESInet info and PSAP info may be a FQDN, URL or URI. Thisinformation is retrieved given a geographical area and can be stored atthe OEM cloud and/or at the local deployment.

Further, a domain may span several areas, including regions orcountries. For emergencies, a DNS lookup may return a local server IPAddress to handle emergency calls for that region or geographic area.

Therefore, based on the above, emergency information may be added eitherat the deployment network or at the OEM cloud.

Emergency Information Added at the Deployment Network

In accordance with this aspect of the present embodiment, the solutionis based on MUD. It consists of a MUD manager looking up the localESInet or secondary server and then including that information in theaccess control list or firewall setup as part of the onboarding of theIoT device.

Reference is now made to FIG. 13 , which shows a more detailed view ofmessages 830, 832, 834, 840 and 844 from FIG. 8 . In the embodiment ofFIG. 13 , an IoT device 1310 communicates with a local domain 1311.Within local domain 1311, a switch 1312 and MUD manager 1316 exist.

A server lookup function 1317 may include an ESInet lookup.

Further, an OEM domain 1320 includes a MUD server 1322.

For the emergency services example, emergency contacts are locallyrelevant ESInet server(s) and/or PSAP addresses, including but notlimited to an IP address, SIP URI, among other options. These can beknown at the MUD manager 1316 by being looked up or stored either by aspecial entity such as the server lookup entity 1317 or by the MUDmanager itself.

The process outlined in the embodiment of FIG. 13 starts with the IoTdevice 1310 sending the MUD URL to the MUD manager 1316 in message 1330.Message 1330 may be sent via the switch 1312.

MUD manager 1316 obtains a MUD file, which may include a trigger in somecases. This is done by sending the URI to the MUD server 1322 in message1332 and receiving the MUD file and potentially a trigger in message1334 from MUD server 1322.

The MUD manager 1316 may make a regular or normal-use policy and it mayalso make a secondary policy such as an emergency policy. The emergencypolicy may, for example, be made by augmenting a regular use policy. Thecreation of the secondary policy may be based on the stored emergencycontact information or other secondary information. These policies maybe sent to switch 1312 in message 1340.

The MUD manager 1316 may then tell the IoT device 1310 of the ESInetusing message 1344.

Emergency (Secondary) Information Added at the OEM Cloud

In some embodiments, the OEM may have both the MASA server from theBRSKI and a MUD server. In other cases, the OEM may just have the MUDserver, and optionally, a secondary service (for example ESInet) lookupfunction that takes a geographic area and returns an FQDN, URL or URI ofthe locally-relevant secondary/emergency services ESInet or PSAP. Theembodiments described below will reference the emergency services as thesecondary services. However, this not limiting and other forms ofsecondary services are possible.

In accordance with the first case, the OEM has both the MASA server andthe MUD server. In this case, the MASA server looks up thelocally-relevant ESInet in at least one of two ways.

A first way includes a direct look up, using an ESInet look up function.

A second way includes looking up in an Ownership tracker if one isemployed, assuming that the Ownership tracker records an IoT devicedeployment network, location and the ESInet for that location. Thelocally-relevant ESInet is the ESInet servicing the local domain asreported by the BRSKI Registrar, or obtained from a look up of thesource IP address of the BRSKI traffic. The MASA server tells the MUDserver of the local emergency FQDNs, and the MUD server includes them ina MUD file.

Optionally, this operation is triggered when the MUD server asks theMASA server to look up the local emergency FQDN, URI or URL.

Reference is now made to FIG. 14 , which shows an architecture in whichthe BRSKI Registrar and the MUD manager are assumed to communicate or beco-located in a local domain. In the example of FIG. 14 , at the OEMside, the BRSKI MASA server and the MUD server have a securecommunication channel.

Further, in this architecture, “Emergency Contacts” or “ESInet” arelocally relevant ESInet server(s) and/or PSAP addresses, including butnot limited to IP addresses, SIP URI, FQDN, URI or URL, among others.Further, the MASA server has access to, or is able to obtain, suchinformation.

In particular, in the embodiment of FIG. 14 , IoT device 1410communicates with a local domain 1411. Local domain 1411 includes aswitch 1412, a MUD manager 1414, and a registrar/AAA 1416.

The OEM domain 1420 includes the MASA server 1422 and a MUD server 1424.

At message 1430, the IoT device 1410 sends the MUD URL to the MUDmanager 1414. The MUD manager 1414 may then tell the BRSKI Registrar ofthe MUD URL (not shown).

In message 1432, the IoT device 1410 sends a BRSKI Voucher request tothe registrar/AAA 1416.

The registrar/AAA 1416 may then send the voucher (authenticity) request1440 to the MASA server 1422, containing a MUD URL and a locality. Forexample, such locality may include the current state, province, orcountry, among other such geographic information.

The MASA server may then determine the authenticity of the IoT device1410, as shown at block 1442.

The MASA server may then look up the ESInet for that locality. This maybe done, for example, by querying an Ownership tracker 1426, as seenwith arrow 1442. This may be done if the information for such Ownershiptracker is provisioned along with the domain of the deployed IoT device1410. Alternatively, or in addition, it may involve querying an ESInet(or other secondary server) lookup 1428, as shown with arrow 1446, forexample based on a geographical region.

The MASA server 1422 may then send a message 1450 to MUD server 1424using the MUD URL and asks MUD server 1424 for the MUD file for IoTdevice 1410. The MASA server 1422 may optionally send the MUD server1424 the ESInet address that was looked up using arrows 1444 and/or1446.

The MUD server 1424 then sends the MUD file in message 1452 to MASAserver 1422, optionally including the ESInet address in the MUD file.

In message 1454, the MASA server 1422 returns the authenticity verdictfor the IoT device 1410, along with the MUD file, to the MUD manager1414. Further, message 1454 may contain either emergency contactinformation (e.g., ESInet address that was obtained) or another MUD filefor secondary use.

The registrar/AAA 1416 completes the authentication/authorization of theIoT device 1410 using the authenticity verdict.

The MUD manager 1414 makes two policies for the switch 1412 of the IoTdevice 1410. One of the policies is for regular use and the other of thepolicies is for secondary use. The policy for secondary use includesallowing communications between the IoT device and the secondary servercontact (e.g., ESINet) that was obtained from message 1454. In otherembodiments, the MUD manager 1412 may combine the two policies into one.The regular and secondary policies are then provided to switch 1412 inmessage 1460.

Further, the determined Secondary Server address may be reported to theIoT device 1410 in message 1462.

In the case where no BRSKI nodes exists, a MUD server looks up theESInet address, for example the FQDN, URI, URL, and/or SIP URI, amongother options, for the geographic area as given by the MUD manager ordetermined from the source IP address of the endpoint that provided thetraffic. The MUD server then includes this “emergency contact”information in the MUD file for that device and re-signs that MUD file.Alternatively, the MUD server may return the information to the MUDmanager separately from the MUD file, or in an emergency-use MUD file.Reference is now made to FIG. 15 .

In the embodiment of FIG. 15 , an IoT device 1510 communicates with alocal domain 1511. Local domain 1511 includes a switch 1512 and a MUDmanager 1514. OEM domain 1520 includes MUD server 1524.

In the example of the FIG. 15 , “emergency contacts” are addresses oflocally-relevant ESInet server(s) and/or PSAP addresses, including, butnot limited to, FQDN, URI, URL, IP addresses, SIP phone numbers, amongothers. A MUD server 1524 has access to this information.

The MUD URL is sent from IoT device 1510 to the MUD manager 1514, asshown by message 1530.

The MUD manager 1514 then contacts the MUD server 1524 in the OEM domainvia, for example, an HTTPS GET, and includes the locality of the localdomain, and optionally an identifier of the device, in the message 1540.The locality may include any geographic indicator, including state,province, country, among other options.

The MUD server 1524 obtains local domain emergency information from anESInet/Secondary Server Lookup Entity 1528 that looks up suchinformation based on the location information provided by MUD manager1514. Alternatively, the MUD server gets that information directly froman Ownership tracker 1526, assuming such database stores some deviceidentifier and its deployed location and Emergency contact information;the MUD server provides the device identifier to the Ownership trackerand obtains the Emergency contact information (e.g., ESInet) orsecondary server contact information for that device. These look ups areshown with arrows 1544 and 1546 respectively in the embodiment of FIG.15 .

MUD server 1524 then incorporates this ESInet information in one ofvarious ways. In a first way, the MUD server 1524 may modify the MUDfile to add a MUD URL for a different secondary server. In a second way,the MUD server may add emergency/secondary contact information to theMUD file and re-sign that MUD file. In a third way, the MUD server 1524may make a new secondary MUD file to return along with the original MUDfile. Other options are possible.

Once the ESInet/Secondary Server information is incorporated, the MUDserver 1524 then returns this information in message 1550 to MUD manager1514.

The MUD manager 1514, following the general procedures of IETF RFC 8520for writing policies out of MUD files, may make two policies for theswitch 1512 of the IoT device 1510. A first policy would be for regularuse, and another policy would be for secondary use. In some cases, theMUD manager 1514 may combine both into one policy, potentially afterfetching the emergency-use MUD file from another MUD file server asprovided above.

The regular and secondary policies may then be provided to switch 1512in message 1560.

Where to Initiate a Connection

In the embodiments of FIGS. 7 to 15 , once an emergency occurs, a devicewill need to know where to initiate the emergency connection. In casethe device already has the FQDN of the emergency services stored as partof the configuration as described above, then when the device getsinstructed by the IoT service platform server to switch to an emergencymode, then at that time the IoT device can do a DNS query for the FQDNof the emergency services it has stored. The router or switch can sniffthe IP address coming back from the DNS server and then configure theACL to allow connectivity to this address. This procedure is similar tothat employed by application-aware firewalls.

In case the device does not have the FQDN of the emergency servicesstored, an instruction from the switch or router or from the IoTplatform server to the IoT device to switch to the emergency mode mayalso contain the URL of the IP address(es) of the locally-relevantservice IP-level entities that this device is asked to now be preparedto send data to.

Message Formats

Various approaches can be applied to signal to the MUD manager that anemergency (secondary) policy exists for the IoT device, and how toretrieve it as part of the IoT device onboarding. In a first option, thedevice comes with or emits two different MUD URLs, one meant to retrievethe routine operation MUD file, and the other for an emergency/secondaryoperation MUD file. The MUD manager then can retrieve both, in anyorder.

For example, the URLs may be in the form described in Table 1 below.

TABLE 1 Example MUD URLs Regular “mud-url”:“https://iot-device.example.com/name” Secondary “mud-url”:“https://iot-device-emergency.example.com/name”

In another option, an IoT device emits a MUD URL, but also emits anothernew data field indicating the existence of an emergency policy. Forexample, a field may be called “emergency-policy-exists”. Thisinformation may be printed or showed in the device manual, either paperor online, on a label on the device, through an additional QR code,among other options. This new data field is processed by the MUDmanager, which then has to find the location of the emergency MUD file.

From these signaling options, the MUD manager has this foreknowledge ofan existence of an emergency policy from the fact that the IoT Device(Thing), in one case, may change the way it uses DHCP, if DHCP is theway it is configured to use in the first place. The modification is thatthe DHCP option defined in section 10 of RFC 8520 can contain the URI ofthe emergency-use MUD file appended after a space after the MUD URIstring, as permitted by RFC 8520, for example.

In a second case, the MUD manager has this foreknowledge of an existenceof an emergency policy from the fact that the IoT Device (Thing) changesthe way it uses LLDP, if LLDP is the way it is configured to use in thefirst place. The modifications would be an extension with a new subtype.

In a third case, MUD manager has the foreknowledge of an existence of anemergency policy from the fact that the IoT Device (Thing) presents adevice certificate that includes an additional extension holding theemergency MUD URI.

Details on the specific changes to the signaling required to achieve theapproach of Table 1 above are now disclosed as ways to extend the MUDRFC. Similar extensions could be made for the approach adding a new datafield.

In one case, the extension could be via the “reserved” string (1 octet)in the MUD URL DHCP, pursuant to section 10 of IETF RFC8520.Specifically, if the MUD manager knows the URL of the emergency-useMUD file, then the DHCP approach is modified in accordance with thefollowing. Following a space after the MUDstring, anemergencyuseMUDstring is added, as shown, for example in bold in Table 2below.

TABLE 2 Example IPv4 MUD URL DHCP code len MUDstringemergencyUseMUDstring

Table 2 shows an example for IPv4. An alternative for IPv4 is shown withregards to Table 3 below, which adds a new field for the emergency useMUD string.

TABLE 3 Example IPv4 MUD URL DHCP code total-len (or count) lenMUDstring1 len MUDstring2

For IPv6, an option is shown with regards to Table 4 below.

TABLE 4 Example IPv6 MUD URL DHCP 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 45 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 OPTION_MUD_URL_V6 option-lengthMUDstring <space>    emergencyUseMUDstring

The above therefore provides the DHCP option.

For the LLDP option, according to IETF RFC 8520, an LLDP extension wasdefined to hold MUD URLs. A new subtype could be introduced tovendor-specific event extensions to carry the new emergency MUD stringfor the emergency use MUD file (or other secondary use MUD file).

An addition to the LLDP vendor-specific frame is shown in bold withregard to Table 5 below.

TABLE 5 Example LLDP vendor-specific frame for eMUDstring OUI = TLV Type= len 00 00 5E subtype = 2 eMUDstring 127 (7 bits) (9 bits) (3 octets)(1 octet) (1-255 octets) where: TLV Type = 127 indicates avendor-specific TLV len = indicates the TLV string length OUI = 00 00 5Eis the organizationally unique identifier of IANA subtype = 2 (asassigned by IANA for the eMUDstring) eMUDstring = the length MUST NOTexceed 255 octets

From the example of Table 5 above, the subtype actually assigned couldbe different from 2, but would not be 1 since this is already defined.

For the third case, where the IoT Device (Thing) presents a devicecertificate that includes a new extension for IEEE 802.1 ARcertificates. Such new extension may be defined to signal the presenceand possibly location of emergency-use MUD files. Generally, this wouldinvolve IETF standardization processes.

Referring to Table 6 below, a new extension follows that defined in theMUD extension. The code is found in section 11 of IETF RFC 8520, and theadded extensions are provided in bold in Table 6 below.

TABLE 6 Example extension to IEEE 802.1AR certificates <CODE BEGINS>MUDURLExtnModule-2016 { iso(1) identified-organization(3) dod(6)internet(1) security(5) mechanisms(5) pkix(7) id-mod(0)id-mod-mudURLExtn2016(88) } DEFINITIONS IMPLICIT TAGS ::= BEGIN <...> ---- Certificate Extensions -- MUDCertExtensions EXTENSION ::= {ext-MUDURL | ext-emMUDURL | ext-MUDsigner, ... } ext-MUDURL EXTENSION::= { SYNTAX MUDURLSyntax IDENTIFIED BY id-pe-mud-url } ext-emMUDURLEXTENSION ::= { SYNTAX MUDURLSyntax IDENTIFIED BY id-pe-mud-url }id-pe-mud-url OBJECT IDENTIFIER ::= {id-pe 25 } MUDURLSyntax ::=IA5String ext-MUDsigner EXTENSION ::= { SYNTAX MUDsignerSyntaxIDENTIFIED BY id-pe-mudsigner } id-pe-mudsigner OBJECT IDENTIFIER ::={id-pe 30 } MUDsignerSyntax ::= Name <...>

Alternative embodiments exist for signaling the existence of theemergency or secondary MUD file. In an alternative class of approaches,the MUD manager learns of the need to retrieve the MUD file withoutadvanced signaling from the IoT device that such policy exists.

For example, in one case, the device emits a MUD URL, as currentlyspecified, but the server sends back two separate MUD files, one forroutine conditions, and the other for secondary or emergency ones.

In another case, the device may emit one mud URL as currently specified,but the MUD file that is returned from the MUD server to the MUD managerhas additional separate entries, such as extensions, for emergencybehavior definition. For example, a new field “mud-emergency-url”,and/or new “from-device-emergency-policy”, “to-device-emergency-policy”,or simply “Emergency policy may exist”.

In the case where the URL is given, the MUD manager may need to retrievethis file as well, again via https/GET MUD URL. Alternatively, the MUDmanager may then need to find the location of the emergency MUD file.

Triggers

With regards to triggers, one issue is how to signal in a MUD fileemergency triggering information. Since ACL configuration is highlydependent on firewall implementation, in one case the emergency triggerinformation signaled in the MUD file is a string for a human user(network administrator) to make use of. However, in other cases it maybe in a different, machine readable, form.

Therefore, a new element in the MUD file indicates the triggering of anemergency situation in terms of data that is available to the device. Inaddition, or alternatively, there could be two trigger elements: one tosignal the transition from normal to emergency, and another one tosignal the transition from emergency back to normal.

An example of a single triggering element is shown in bold with regardsto Table 7 below.

TABLE 7 Example new element in a MUD file module: ietf-mud +--rw mud!+--rw mud-version uint8 +--rw mud-url inet:uri +--rw last-updateyang:date-and-time +--rw mud-signature? inet:uri +--rw cache-validity?uint8 +--rw is-supported boolean +--rw systeminfo? string +--rwmfg-name? string +--rw model-name? string +--rw firmware-rev? string+--rw software-rev? string +--rw documentation? inet:uri +--rwemergency-trigger? string +--rw extensions* string +--rwfrom-device-policy | +--rw acls | +--rw access-list* [name] | +--rw name-> /acl:acls/acl/name <... >

An example showing text to display to the user is provided in Table 7above.

In the example of Table 8 below, one trigger is for transitioning from anormal operation mode to an emergency operation mode. It is assumed thatthe same trigger may be used for transitioning from the emergencyoperation mode to a normal operation mode. Changes are shown in bold.

TABLE 8 Example trigger { ″ietf-mud:mud″: {  ″mud-version″: 1, ″mud-url″: ″https://lighting.example.com/lightbulb2000″, ″last-update″: ″2019-01-28T11:20:51+01:00″,  ″cache-validity″: 48, ″is-supported″: true,  ″systeminfo″: ″The ACME Example Temperaturemeter″,  ″emergency-trigger″: ″Temperature exceeding 140degrees F.″, ″from-device-policy″: {   ″access-lists″: {    ″access-list″: [     {    ″name″: ″mud-76100-v6fr″     }    ]   }  }

Alternatively, two emergency triggers may exist, for example as shown inbold in Table 9 below.

TABLE 9 Example with two emergency triggers { ″ietf-mud:mud″: { ″mud-version″: 1,  ″mud-url″:″https://lighting.example.com/lightbulb2000″,  ″last-update″:″2019-01-28T11:20:51 +01:00″,  ″cache-validity″: 48,  ″is-supported″:true,  ″systeminfo″: ″The ACME Example Temperature meter″, ″normal2emergency-trigger″: ″Temperature exceeding 140degrees F.″, ″emergency2normal-trigger″: ″Temperature below 130 degrees F.″, ″from-device-policy″: {    ″access-lists″: {     ″access-list″: [     {      ″name″: ″mud-76100-v6fr″      }     ]    }  }

While the above the signaling is focused on the emergency use case,similar amendments could be made to such signaling for any othersecondary use case for an Internet of Things device. The presentdisclosure is therefore not limited to emergency use cases.

Hardware

The servers, IoT devices, gateways, relays, switches, MUD managers,Ownership Trackers, ESInet lookups, MASA servers, MUDS servers, andelectronic devices performing the methods described above may be anyelectronic device or network node. Such electronic device or networknode may include any type of computing device, including but not limitedto, mobile devices such as smartphones or cellular telephones. Examplescan further include fixed or mobile user equipments, such as IoTdevices, endpoints, home automation devices, medical equipment inhospital or home environments, inventory tracking devices, environmentalmonitoring devices, energy management devices, infrastructure managementdevices, vehicles or devices for vehicles, fixed electronic devices,among others. Vehicles includes motor vehicles (e.g., automobiles, cars,trucks, buses, motorcycles, etc.), aircraft (e.g., airplanes, unmannedaerial vehicles, unmanned aircraft systems, drones, helicopters, etc.),spacecraft (e.g., spaceplanes, space shuttles, space capsules, spacestations, satellites, etc.), watercraft (e.g., ships, boats, hovercraft,submarines, etc.), railed vehicles (e.g., trains and trams, etc.),pedestrians and bicycles and other types of vehicles including anycombinations of any of the foregoing, whether currently existing orafter arising.

One simplified diagram of a network element or an electronic device isshown with regard to FIG. 16 .

In FIG. 16 , device 1610 includes a processor 1620 and a communicationssubsystem 1630, where the processor 1620 and communications subsystem1630 cooperate to perform the methods of the embodiments describedabove. Communications subsystem 1620 may, in some embodiments, comprisemultiple subsystems, for example for different radio and wiredtechnologies.

The processor 1620 is configured to execute programmable logic, whichmay be stored, along with data, on device 1610, and shown in the exampleof FIG. 16 as memory 1640. Memory 1640 can be any tangible,non-transitory computer readable storage medium. The computer readablestorage medium may be a tangible or in transitory/non-transitory mediumsuch as optical (e.g., CD, DVD, etc.), magnetic (e.g., tape), flashdrive, hard drive, or other memory known in the art.

Alternatively, or in addition to memory 1640, device 1610 may accessdata or programmable logic from an external storage medium, for examplethrough communications subsystem 1630.

The communications subsystem 1630 allows device 1610 to communicate withother devices or network elements and may vary based on the type ofcommunication being performed. Further, communications subsystem 1630may comprise a plurality of communications technologies, including anywired or wireless communications technology.

Communications between the various elements of device 1610 may bethrough an internal bus 1660 in one embodiment. However, other forms ofcommunication are possible.

The embodiments described herein are examples of structures, systems ormethods having elements corresponding to elements of the techniques ofthis application. This written description may enable those skilled inthe art to make and use embodiments having alternative elements thatlikewise correspond to the elements of the techniques of thisapplication. The intended scope of the techniques of this applicationthus includes other structures, systems or methods that do not differfrom the techniques of this application as described herein, and furtherincludes other structures, systems or methods with insubstantialdifferences from the techniques of this application as described herein.

While operations are depicted in the drawings in a particular order,this should not be understood as requiring that such operations beperformed in the particular order shown or in sequential order, or thatall illustrated operations be performed, to achieve desirable results.In certain circumstances, multitasking and parallel processing may beemployed. Moreover, the separation of various system components in theimplementation descried above should not be understood as requiring suchseparation in all implementations, and it should be understood that thedescribed program components and systems can generally be integratedtogether in a signal software product or packaged into multiple softwareproducts.

Also, techniques, systems, subsystems, and methods described andillustrated in the various implementations as discrete or separate maybe combined or integrated with other systems, modules, techniques, ormethods. Other items shown or discussed as coupled or directly coupledor communicating with each other may be indirectly coupled orcommunicating through some interface, device, or intermediate component,whether electrically, mechanically, or otherwise. Other examples ofchanges, substitutions, and alterations are ascertainable by one skilledin the art and may be made.

While the above detailed description has shown, described, and pointedout the fundamental novel features of the disclosure as applied tovarious implementations, it will be understood that various omissions,substitutions, and changes in the form and details of the systemillustrated may be made by those skilled in the art. In addition, theorder of method steps is not implied by the order they appear in theclaims.

When messages are sent to/from an electronic device, such operations maynot be immediate or from the server directly. They may be synchronouslyor asynchronously delivered, from a server or other computing systeminfrastructure supporting the devices/methods/systems described herein.The foregoing steps may include, in whole or in part,synchronous/asynchronous communications to/from thedevice/infrastructure. Moreover, communication from the electronicdevice may be to one or more endpoints on a network. These endpoints maybe serviced by a server, a distributed computing system, a streamprocessor, etc. Content Delivery Networks (CDNs) may also provide mayprovide communication to an electronic device. For example, rather thana typical server response, the server may also provision or indicate adata for content delivery network (CDN) to await download by theelectronic device at a later time, such as a subsequent activity ofelectronic device. Thus, data may be sent directly from the server, orother infrastructure, such as a distributed infrastructure, or a CDN, aspart of or separate from the system.

Typically, storage mediums can include any or some combination of thefollowing: a semiconductor memory device such as a dynamic or staticrandom access memory (a DRAM or SRAM), an erasable and programmableread-only memory (EPROM), an electrically erasable and programmableread-only memory (EEPROM) and flash memory; a magnetic disk such as afixed, floppy and removable disk; another magnetic medium includingtape; an optical medium such as a compact disk (CD) or a digital videodisk (DVD); or another type of storage device. Note that theinstructions discussed above can be provided on one computer-readable ormachine-readable storage medium, or alternatively, can be provided onmultiple computer-readable or machine-readable storage media distributedin a large system having possibly a plurality of nodes. Suchcomputer-readable or machine-readable storage medium or media is (are)considered to be part of an article (or article of manufacture). Anarticle or article of manufacture can refer to any manufactured singlecomponent or multiple components. The storage medium or media can belocated either in the machine running the machine-readable instructions,or located at a remote site from which machine-readable instructions canbe downloaded over a network for execution.

In the foregoing description, numerous details are set forth to providean understanding of the subject disclosed herein. However,implementations may be practiced without some of these details. Otherimplementations may include modifications and variations from thedetails discussed above. It is intended that the appended claims coversuch modifications and variations.

1. A method at a network element comprising: receiving data from anInternet-of-Things (IoT) device through a first network, the IoT deviceoperating in a normal mode of operation; determining that a conditionfor switching the IoT device to a secondary mode of operation has beenmet; and sending a command to a switch associated to the IoT device tooperate in a secondary mode of operation, wherein the command causes theswitch to route data from the IoT device to a secondary server.
 2. Themethod of claim 1, wherein the network element is an IoT applicationserver.
 3. The method of claim 1, wherein the secondary server is on asecondary network distinct from the first network.
 4. The method ofclaim 1, wherein determining that the condition has been met is based ona message from the secondary server.
 5. The method of claim 1, whereindetermining that the condition has been met is based on data from theIoT device.
 6. The method of claim 4, wherein the message from thesecondary server comprises an indication to route data from the IoTdevice to the secondary server.
 7. The method of claim 1, wherein thecommand causes the switch to route data from the IoT device to thenetwork element and to the secondary server.
 8. The method of claim 1,further comprising: determining that the condition is no longer met; andsending a second command to the switch to operate in a normal mode ofoperation, wherein the second command causes the switch to route datafrom the IoT device to the network element.
 9. The method of claim 8,wherein determining that the condition is no longer met is based on atleast one of a second message from the secondary server, data from theIoT device, and a timer expiring.
 10. The method of claim 1, furthercomprising performing a lookup for a network address of the secondaryserver based on a geographic location of the IoT device.
 11. A networkelement, comprising: a processor; and a communications subsystem;wherein the processor and the communications subsystem cooperate to:receive data from an Internet-of-Things (IoT) device through a firstnetwork, the IoT device operating in a normal mode of operation;determine that a condition for switching the IoT device to a secondarymode of operation has been met; and send a command to a switchassociated to the IoT device to operate in a secondary mode ofoperation, wherein the command causes the switch to route data from theIoT device to a secondary server.
 12. The network element of claim 11,wherein the network element is an IoT application server.
 13. Thenetwork element of claim 11, wherein the secondary server is on asecondary network distinct from the first network.
 14. The networkelement of claim 11, wherein determining that the condition has been metis based on a message from the secondary server.
 15. The network elementof claim 11, wherein determining that the condition has been met isbased on data from the IoT device.
 16. The network element of claim 14,wherein the message from the secondary server comprises an indication toroute data from the IoT device to the secondary server.
 17. The networkelement of claim 11, wherein the command causes the switch to route datafrom the IoT device to the network element and to the secondary server.18. The network element of claim 11, wherein the processor and thecommunications subsystem further cooperate to: determine that thecondition is no longer met; and send a second command to the switch tooperate in a normal mode of operation, wherein the second command causesthe switch to route data from the IoT device to the network element. 19.The network element of claim 18, wherein determining that the conditionis no longer met is based on at least one of a second message from thesecondary server, data from the IoT device, and a timer expiring.
 20. Anon-transitory computer-readable medium having stored thereon executablecode for execution by a processor of a network element, the executablecode comprising instructions for: receiving data from anInternet-of-Things (IoT) device through a first network, the IoT deviceoperating in a normal mode of operation; determining that a conditionfor switching the IoT device to a secondary mode of operation has beenmet; and sending a command to a switch associated to the IoT device tooperate in a secondary mode of operation, wherein the command causes theswitch to route data from the IoT device to a secondary server.